SSF S t a n d a r d	스마트도시단체표준 제정일: 20xx년 xx월 xx일 SSF-xx-xxxx 개정일: 20xx년 xx월 xx일
		SSF 표준 작성 샘플
		(Example for Writing on SSF Standard)

스마트도시표준화포럼 표준	제정일 : 20XX년 XX월 XX일

SSF-XX-XXXX

스마트도시 통합운영센터 플랫폼

서비스 인터페이스 모델

(The Service Interface Model for the Integrated Platform of Smart City Operation Center)

스마트도시표준화 포럼

※ 본문 작성 방법

- 표준의 목적, 주요 내용, 기대 효과 등을 각 항목에 맞추어 간략하게 작성

- 11포인트 명조계열로 작성

- ※표시의 굴림체 붉은색 굵은 글씨는 작성요령 설명

서   문

1. 표준의 목적

스마트도시 사업이 여러 지방자치단체에서 개별적으로 추진됨에 따라 각 스마트도시 사업에서 각각 개별적인 서비스를 개발하여 운영하고 있다. 이러한 서비스들은 단일화된 표준이 없어 각자의 필요에 의하여 설계 및 구현되고 있는 상황이다. 이 과정에서 국가적인 중복 투자가 발생할 뿐 아니라 스마트도시 통합운영센터와 서비스의 상호 운용성을 저해하고 있다. 따라서 스마트도시 통합운영센터의 플랫폼과 단위 서비스 사이의 서비스 인터페이스에 대한 단일화된 표준의 필요성이 제기되었다. 이에 본 표준은 스마트도시 통합운영센터의 플랫폼과 단위 서비스 사이에 필요한 서비스 인터페이스를 제시하여 투자의 효율성을 높이고, 상호 운용성의 기초를 제공함을 목적으로 한다. 이를 위하여 본 표준에서는 스마트도시 서비스 인터페이스를 기능에 따라 분류하고 각 인터페이스의 정의를 제시한다.

2. 주요 내용 요약

스마트도시 통합운영센터는 다양한 단위 서비스 간의 통합을 구현하는데, 다양한 시설물 및 연관된 단위 서비스를 통합하기 위해서는 표준화된 인터페이스 모델이 필요하다. 또한 표준화된 인터페이스는 스마트도시 통합운영센터의 도시간 상호 운용성을 높여줄 수 있다. 본 표준에서는 스마트도시 통합운영센터의 플랫폼과 단위 서비스 사이에 필요한 서비스 인터페이스의 공통된 핵심 요소를 설명한다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 표준은 국내 스마트도시 통합운영센터와 단위 서비스를 구축함에 있어 발생할 수 있는 중복 투자를 최소화하고 관련 기술의 발전과 스마트도시 활성화에 기여할 것이다. 또한 스마트도시 통합운영센터와 서비스에 대한 상호 운용성을 확보하여 스마트도시 활성화에 일조할 것이다.

4. 참조 표준(권고)

4.1 국외표준(권고)

- OGC 06-121r3, OGC Web Services Common Specification, Open Geospatial Consortium Inc., 2007

- The Application Level Events (ALE) Specification, Version 1.1, EPCglobal, 2008

4.2 국내표준

해당 사항 없음

5. 참조표준(권고)과의 비교

5.1 참조표준(권고)과의 관련성

※ 가능한 한 상세히 기술하며, 참조 표준과의 대비, 국제 표준의 주변 상황 등을 기술하며, 추가/삭제/수정한 항목이 있을 경우에는 아래 비교표를 통해 명확히 기술한다.

본 표준이 서비스 인터페이스가 가져야 할 공통된 핵심 요소를 기술(記述)하고 있으므로 인터페이스의 표준을 상세한 명세를 통하여 제시하기에 어려움이 있다. 이와 관련하여 참조표준들이 인터페이스를 기술하는 방식을 참고로 하여 본 표준을 작성하였다.

5.2 참조한 표준(권고)과 본 표준의 비교표

해당 사항 없음(본 표준과 참조표준의 기술(技術)적 관련성이 없어 비교표를 생략함)

※ 개정 표준일 경우, 개정 전 표준과의 비교표 작성

단체표준안	(표준개정시, 개정전 표준)	참조표준 :	비고

6. 지적재산권 관련사항

해당 사항 없음

7. 적합인증 관련사항

7.1 적합인증 대상 여부

해당 사항 없음

7.2 시험표준제정여부(해당 시험표준번호)

해당 사항 없음

8. 표준의 이력

판수	제/개정일	제․개정내역
제1판	2011.03.25	제정

목   차

1. 개 요	1

(항목번호. 항목제목(Tab|↔|)	쪽수)

2. 표준의 구성 및 범위	1

3. 용어정의	1

4. 인터페이스 표준 모델 정의	2

부록 I. 서비스 연계 시나리오	4

<본문 작성시 참고사항 >

- 본문의 순서는 1, 1.1, 가 등으로 하며, 본문은 11 포인트 명조계열로 작성함. 다만, 본문의 내용 중 중요부문은 고딕계열 사용 가능

- 표 본문 내용은 양식에 따라 자유롭게 작성)

- 그림 번호는 해당 절에 따라 1-1,2-1로 명명

- (※) 표시는 해당 항목의 작성 요령을 의미함

스마트도시표준화포럼 표준(국문)

스마트도시 통합운영센터 플랫폼 서비스 인터페이스 모델

The Service Interface Model

for the Integrated Platform of u-City Operation Center

1. 개요

스마트도시 통합운영센터의 플랫폼과 각 단위 서비스가 서로 연동될 수 있도록 서비스 인터페이스에 대한 표준을 정의한다.

2. 표준의 구성 및 범위

본 표준은 스마트도시 통합운영센터의 플랫폼과 단위 서비스 사이에 필요한 서비스 인터페이스를 기능에 따라 분류하고 각 인터페이스의 정의를 기술하고 있다. 본 표준이 다루는 인터페이스는 [그림2-1]과 같은 참조 모델에 기반하고 있다. 서비스 인터페이스는 서비스와 스마트도시 통합운영센터의 플랫폼 사이의 인터페이스를 지칭하며, u-Infra 인터페이스는 스마트도시 통합운영센터의 플랫폼과 u-Infra 사이의 인터페이스를 지칭한다. 본 표준은 이 가운데 서비스 인터페이스만을 대상으로 한다.

[그림 -1] 서비스 인터페이스 참조 모델

서비스 인터페이스의 기능에 따른 분류는 첫 번째로 제어 인터페이스, 두 번째로 데이터 조회 인터페이스, 세 번째로 데이터 전송 인터페이스로 구성되어 있다. 기능적으로 분류된 인터페이스는 다시 기능의 복잡도에 따라서 기본 인터페이스와 응용 인터페이스로 분류된다.

한편, 각 서비스 인터페이스의 정의는 다음과 같이 구성되어 있다. 첫째, 인터페이스가 인자 또는 결과로 사용할 자료형의 이름과 설명으로 구성된 자료형의 정의, 둘째, 인터페이스 표준을 기능적으로 구분하고, 다시 기본 인터페이스와 응용 인터페이스로 구분한 인터페이스 표준의 분류, 셋째, 제어 인터페이스, 데이터 조회 인터페이스, 데이터 전송 인터페이스에 속하는 메소드명, 인자 및 결과명과 그에 해당하는 자료형을 정의하고 그에 대한 설명을 제시하였다.

본 표준은 스마트도시 통합운영센터와 서비스의 상호 운용성을 위하여 둘 사이에 존재할 수 있는 공통된 인터페이스 제시를 목적으로 한다. 이에 본 표준을 적용할 수 있는 범위는 첫째, 스마트도시 추진을 위한 지방자치단체 또는 공공부문, 둘째, 스마트도시 서비스 솔루션 개발자, 셋째, 민간 스마트도시 서비스 사업자, 넷째, 스마트도시 서비스 표준 개발자 등이 있다.

3. 용어정의

3.1. 용어 정의

용어의 표기는 한국정보통신기술협회의 정보통신용어사전 표기에 따른다.

가. 스마트도시 (Smart City)

첨단 정보통신 인프라와 스마트 기술 및 정보 서비스가 융합된 차세대 정보화 도시이다. 스마트도시는 첨단 정보통신 인프라와 정보 서비스를 도시공간에 융합하여 도시생활의 편의 증대, 체계적인 도시 관리에 의한 안정보장 및 도시기능의 지능화에 의한 삶의 질 향상 등 도시 제반 기능을 혁신시킬 수 있는 차세대 정보화 도시를 의미한다. 이와 동시에 『스마트도시 조성 및 산업진흥 등에 관한 법률』(법률 제14718호, 2017년 3월 1일)제2조1항에 정의된 “스마트 도시”를 의미한다.

나. 단위 서비스

하나 이상의 기능의 집합인 스마트도시 구현에 필요한 서비스. 『스마트도시 조성 및 산업진흥 등에 관한 법률』(법률 제14718호, 2017년 3월 1일) 제2조2항에 정의된 “스마트 도시서비스” 그 자체 또는 하위요소가 되는 서비스를 의미한다.

다. 스마트도시 통합운영센터

스마트도시 통합운영센터는 스마트도시의 관리 및 운영을 담당하는 시설이다. 스마트도시를 관리하고 운영하기 위하여 연관된 각 분야의 정보시스템을 연계 및 통합하여 운영한다. 『스마트도시 조성 및 산업진흥 등에 관한 법률』(법률 제14718호, 2017년 3월 1일)제2조3항에 정의된 “스마트 도시의 관리 • 운영에 관한 시설” 그 자체 또는 하위요소가 되는 시설을 의미한다.

라. 통합플랫폼

스마트도시 통합운영센터의 구성요소로서 스마트도시와 연관된 각 분야의 정보시스템을 연계하는 소프트웨어 플랫폼이다.

마. 인터페이스

2개의 시스템이 상호 작용할 수 있도록 접속되는 경계에서 상호 접속하기 위한 조건 및 규약을 의미한다.

바. 상호 운용성

같은 기종 또는 다른 기종의 기기끼리 상호간에 통신할 수 있고, 정보 교환이나 일련의 처리를 정확하기 실행할 수 있는 것을 의미한다.

사. 지리 정보 시스템

지도에 관한 속성 정보를 컴퓨터를 이용해서 해석하는 시스템이다.

4. 인터페이스 표준 모델 정의

본 장에서는 스마트도시 통합운영센터의 플랫폼과 단위 서비스들 간의 서비스 인터페이스를 정의한다. 이를 위해 먼저 필요한 자료형들을 정의하고, 인터페이스들을 기능에 따라 분류하고, 제어, 데이터 조회, 데이터 전송의 각 인터페이스에 대한 상세 정의에 대해 소개한다.

인터페이스의 적용에 관한 상세 예시는 부록Ⅰ. 서비스 시나리오를 참고한다.

4.1. 자료형 정의

본 절에서는 스마트도시 통합운영센터의 서비스 인터페이스를 정의하기 위해 필요한 자료형들에 대해 정의한다. 각각의 자료형들은 스마트도시 통합운영센터가 단위 서비스들을 호출하며 주고 받는 여러 가지 데이터들에 대한 자료형을 의미한다.

[표 4-1] 인터페이스에 필요한 자료형

자료형		설명
DeviceID		대상 디바이스의 식별자로, 대상 디바이스의 예시로는 센서, 사용자 단말, 공공 단말 등이 있다.
DeviceMetadata		디바이스 자체에 관한 데이터로서, 디바이스가 생산하거나 수용할 데이터인 DeviceData와는 구분된다. 예시로는 디바이스 타입(type) 등이 있다.
DeviceData		디바이스가 생산한 데이터 또는 수용할 데이터로서, 데이터 조회 인터페이스나 데이터 전송 인터페이스에 사용한다.
Command		디바이스의 제어를 위한 명령과 인자들을 담는 자료형이다.
Condition		응용 인터페이스에서 추가적인 기능을 수행하기 위한 조건들을 기술하기 위해 사용한다. 아래와 같이 세 가지 분류가 있다.
??	SpatialCondition	공간 및 지역적 조건을 다룬다. 예시로는 지리 정보 시스템의 데이터 등이 있다.
	TemporalCondition	과거 및 미래의 시간적 조건을 다룬다. 예시로는 미래의 특정 시점 또는 과거의 특정 기간 등이 있다.
	EtcCondition	SpatialCondition과 TemporalCondition이 다루지 않는 다른 조건들을 포괄한다. 예시로는 시간적 조건과 공간적 조건이 복합적으로 있는 경우, 또는 온도 등이 있다.
NotificationURI		데이터 조회 인터페이스에서 DeviceData를 지속적으로 수신하고자 할 때(Subscribe), 통합운영센터에서 단위 서비스로 전송할 데이터가 있음을 통지할 때 사용하는 URI이다.
Ack		인터페이스의 결과 값이 성공 혹은 실패로만 구성될 경우 사용하는 자료형이다.

4.2. 인터페이스 표준의 분류

본 절에서는 스마트도시 통합운영센터의 서비스 인터페이스들을 기능에 따라 분류한다. 서비스 인터페이스들은 크게 제어 인터페이스, 데이터 조회 인터페이스, 데이터 전송 인터페이스로 구분되며, 각각의 인터페이스는 기본과 응용으로 다시 분류된다.

[표 4-2] 인터페이스 표준의 분류

대분류	소분류	인터페이스
제어 인터페이스	기본 인터페이스	디바이스 메타데이터 정보 요청 디바이스 제어 요청
	응용 인터페이스	시간 조건 디바이스 제어 공간 조건 디바이스 제어 기타 조건 디바이스 제어
데이터 조회 인터페이스	기본 인터페이스	디바이스 데이터 조회 시작 (Subscribe) 디바이스 데이터 조회 종료 (Unsubscribe) 디바이스 데이터 조회
	응용 인터페이스	시간 조건 데이터 조회 공간 조건 데이터 조회 기타 조건 데이터 조회
데이터 전송 인터페이스	기본 인터페이스	디바이스로 데이터 전송
	응용 인터페이스	시간 조건 데이터 전송 공간 조건 데이터 전송 기타 조건 데이터 전송

4.3. 제어 인터페이스

제어 인터페이스는 스마트도시 통합운영센터를 통해 각 디바이스에 대한 제어를 요청하는 경우에 이용된다. 기본 제어로는 특정 디바이스에 대한 정보를 요청하는 경우(getDeviceMetadata)와 디바이스가 어떤 기능을 수행하도록 하는 제어 명령을 전달하는 경우(controlDevice)가 있다. 응용 제어로는 시간조건(tcond), 공간조건(scond), 기타조건(econd) 등을 만족시키는 제어 명령을 전달하는 경우(controlDevice)가 있다.

[그림 4-1] 제어 인터페이스 다이어그램

[표 4-3] 제어 인터페이스 명세

구분	메소드명	인자 및 결과	자료형	설명
기본	getDeviceData	id	DeviceID	특정 디바이스가 수집한 데이터 요청
		[결과]	DeviceData
	subscribeDevice Data	id	DeviceID	디바이스가 수집한 데이터 조회 시작
		nURI	NotificationURI
		[결과]	Ack
	unsubscribe DeviceData	id	DeviceID	디바이스가 수집한 데이터 조회 종료
		nURI	NotificationURI
		[결과]	Ack
응용	getDeviceData	id	DeviceID	tcond를 만족하는 시점에 특정 디바이스가 수집한 데이터 조회
		tcond	TemporalCondition
		[결과]	DeviceData
	getDeviceData	scond	SpatialCondition	scond를 만족하는 디바이스들이 수집한 데이터 조회
		[결과]	DeviceData
	getDeviceData	econd	EtcCondition	econd에 명시된 조건 만족하는 디바이스들이 수집한 데이터 조회
		[결과]	DeviceData

4.4. 데이터 조회 인터페이스

데이터 조회 인터페이스는 스마트도시 통합운영센터를 통해 각 디바이스로부터 필요한 정보를 조회하는 경우에 이용된다. 기본 데이터 조회로는 특정 디바이스가 수집한 데이터를 요청하는 경우(getDeviceData), 디바이스가 수집한 데이터에 대한 조회를 시작(subscribeDeviceData) 혹은 종료(unsubscribeDeviceData)하는 경우가 있다. 응용 데이터 조회로는 시간조건(tcond), 공간조건(scond), 기타조건(econd) 등을 만족시키는 데이터 조회를 요청하는 경우(getDeviceData)가 있다.

[그림 4-2] 데이터 조회 인터페이스 다이어그램

[표 4-4] 데이터 조회 인터페이스 명세

구분	메소드명	인자 및 결과	자료형	설명
기본	sendDeviceData	Id	DeviceID	특정 디바이스로 데이터를 전송하여 동작시킴
		Ddata	Devicedata
		[결과]	Ack
응용	sendDeviceData	Id	DeviceID	특정 디바이스로 tcond를 만족시키는 데이터를 전송
		Ddata	DeviceData
		Tcond	TemporalCondition
		[결과]	Ack
	sendDeviceData	Ddata	DeviceData	scond를 만족시키는 데이터를 전송
		scond	SpatialCondition
		[결과]	Ack
	sendDeviceData	econd	EtcCondition	econd를 만족시키는 데이터를 전송
		[결과]	Ack

4.5. 데이터 전송 인터페이스

데이터 전송 인터페이스는 스마트도시 통합운영센터를 통해 각 디바이스에게 필요한 정보를 전송하는 경우에 이용된다. 기본 데이터 전송으로는 특정 디바이스로 데이터를 전송하여 동작시키는 경우(sendDeviceData)가 있으며, 응용 데이터 전송으로는 시간조건(tcond), 공간조건(scond), 기타조건(econd) 등을 만족시키는 데이터 전송을 요청하는 경우(sendDeviceData)가 있다.

[그림 4-3] 데이터 전송 인터페이스 다이어그램

[표 4-5] 데이터 전송 인터페이스 명세

구분	메소드명	인자 및 결과	자료형	설명
기본	getDevice Metadata	id	DeviceID	통합운영센터에 특정 디바이스 정보 요청
		[결과]	DeviceMetadata
	controlDevice	id	DeviceID	통합운영센터에 디바이스의 제어 명령 전달 요청
		cmd	Command
		[결과]	Ack
응용	controlDevice	id	DeviceID	tcond를 만족하는 시점에 특정 디바이스에 제어 명령 전달 요청
		cmd	Command
		tcond	TemporalCondition
		[결과]	Ack
	controlDevice	cmd	Command	scond를 만족하는 디바이스들에 제어 명령 전달 요청
		scond	SpatialCondition
		[결과]	Ack
	controlDevice	cmd	Command	econd에 명시된 조건 만족하는 디바이스에 제어 명령 전달 요청
		Econd	EtcCondition
		[결과]	Ack

4.6. 메시지 흐름

서비스 인터페이스의 메시지 흐름은 유형별로 기술한다. 제어 인터페이스, 데이터 조회 인터페이스, 데이터 전송 인터페이스의 세 가지 인터페이스 분류에서 메시지 흐름은 세 가지 유형이 있다.

가. 유형 1

유형 1은 메소드를 1회 호출하면 스마트도시 통합운영센터로부터 1회의 결과가 반환되는 경우이다. 결과의 자료형은 Ack, DeviceMetadata, DeviceData가 될 수 있다. 다른 유형에 해당하지 않는 모든 메소드는 기본적으로 유형1에 해당한다.

[그림 4-4] 유형 1의 메시지 흐름

나. 유형 2

유형 2는 메소드를 1회 호출하더라도 스마트도시 통합운영센터로부터 1회 이상의 결과가 반환되는 경우이다. 데이터 조회 인터페이스의 subscribeDeviceData, unsubscribe DeviceData 메소드가 이에 해당한다. 메소드 호출에 대한 결과는 Ack 자료형으로 반환되며, 이후에 추가적으로 반환될 결과가 있으면 메소드를 호출할 때 포함된 notificationURI 인자를 통하여 결과를 반환하게 된다.

유형 2에서 subscribeDeviceData메소드는 데이터 조회의 시작을 의미하며, unsubscribeDeviceData는 데이터 조회의 종료를 의미한다. 즉, notificationURI를 통한 결과 반환은 subscribeDeviceData 메소드의 호출 이후부터 unsubscribe DeviceData 메소드의 호출 이전까지 이루어진다.

[그림 4-5] 유형 2의 메시지 흐름

다. 유형 3

유형3은 시간조건, 공간조건, 기타조건 등을 인자로 한 메소드를 호출한 경우이며, 메시지 흐름은 유형1의 그림4-4와 동일하다. 모든 응용 인터페이스가 유형3에 해당한다.

부록Ⅰ. 서비스 연계 시나리오

본 부록에서는 앞에서 정의한 인터페이스들이 어떻게 사용되는지를 설명하기 위하여 시설물 분야와 방범 방재 분야의 네 가지 서비스들을 예시 서비스로 선정하고 각각의 서비스 연계 시나리오 및 인터페이스들의 사용 예시를 기술하였다. 본 서비스 연계 시나리오에 사용된 참조 모델은 [그림 Ⅰ-1]과 같다.

[그림 Ⅰ-1] 서비스 연계 시나리오 참조 모델

Ⅰ.1. 서비스 연계 시나리오 1 – 시설물 분야 서비스

가. 시설물 제어 서비스

- 시설물 제어 서비스는 해당 서비스에 사용되는 다양한 센서나 디바이스의 동작을 위해 [4.3 제어 인터페이스]를 이용하여 스마트도시 통합운영센터에 원하는 동작을 요청한다.

- 각각의 센서와 디바이스들은 각각을 구분하는데 필요한 DeviceID를 가지고 있어서 시설물 제어 서비스는 DeviceID를 사용하여 스마트도시 통합운영센터에 필요한 디바이스에 대해 제어 명령을 전달하거나 전달 받을 수 있다.

- 제어 인터페이스 중controlDevice(DeviceId id, Command cmd) 인터페이스를 사용하여, 특정 ID를 가지는 가로등의 전원을 키고 켜는 제어 명령을 스마트도시 통합운영센터에 전달할 수 있다. 스마트도시 통합운영센터는 Command를 가로등에 전달하고, 가로등은 해당 명령을 수행하여 문제 없이 수행하였을 경우 스마트도시 통합운영센터는 성공 Ack를 반환한다. 이상이 발생하였을 경우에는 실패 Ack를 반환하여 문제가 발생하였음을 알린다. 이 경우의 메시지 흐름은 [그림 Ⅰ-2]와 같다.

[그림 Ⅰ-2] 시설물 제어 서비스 메시지 흐름 예

- 시설물 제어 서비스는 특정 가로등의 ID와 getDeviceMetadata(DeviceId id) 인터페이스를 이용하여 스마트도시 통합운영센터에 해당 가로등 스펙 등의 조회를 요청한다. 앞에서와 마찬가지로 이상이 발생하였을 경우 스마트도시 통합운영센터는 실패 Ack를 반환하여 문제가 발생하였음을 알린다.

- 명시적인 DeviceId를 사용하지 않고 시간, 공간, 또는 기타 조건을 통해 시설물을 관리 할 수 있다. 예를 들어 특정 장소의 지역코드를 공간 조건으로 하여 controlDevice(Command cmd, SpatialCondition scond) 인터페이스를 이용하여 스마트도시 통합운영센터에 제어를 요청하면 해당 지역 전체의 가로등의 전원을 켜거나 끌 수 있다. 마찬가지로 controlDevice(Command cmd, TemporalCondition scond)를 통하여 특정 시간과 관련된 제어가 가능하다. 시간과 공간의 복합 조건 및 기타 조건을 통한 제어는 controlDevice(Command cmd, EtcCondition econd) 인터페이스를 통해 처리한다.

나. 시설물 정보 조회를 통한 유지보수

- 시설물 정보 조회를 통한 유지보수를 담당하는 단위 서비스는 스마트도시 통합운영센터에 시설물의 정보를 지속적으로 조회하여 시설물 유지 보수를 위한 정보를 수집한다. 이 때 [4.4 조회 인터페이스]를 활용한다.

- 지속적인 정보 수집을 수행하고자 하는 시설물의 ID와 정보를 반환할 URI를 이용하여 조회 인터페이스의 subscribeDeviceData(DeviceId id, NotificationURI nURI)을 통하여 처리한다. 일례로 특정 시설물의 온도를 지속적으로 확인하고자 할 때 이 인터페이스를 활용할 수 있다. 이후 해당 시설물의 변화가 감지되면 스마트도시 통합운영센터는 지속적으로 nURI에 정보를 반환한다.

- 지속적인 정보의 조회를 중단하고자 할 때에는 조회 인터페이스의  unSubscribeDevice Data(DeviceId id, NotificationURI nURI)를 이용하여 스마트도시 통합운영센터에 조회 중단을 요청한다. 이렇게 지속적으로 얻은 시설물의 주변 정보를 분석하면 그 정보의 경향성을 발견할 수 있다. 각 시설물은 주변 상태에 따라서 다른 관리를 필요로 하는 경우가 많으며, 이런 방식으로 발견한 경향에 따라서 시설물 관리 방법을 달리 하는 것이 가능하다.

- 시설물 제어 서비스와 마찬가지로 명시적으로 특정 ID를 이용하여 정보를 조회하고자 할 경우 getDeviceData(DeviceId id)를 이용한다. 스마트도시 통합운영센터는 해당 DeviceID에 맞는 디바이스의 DeviceData를 반환해준다. 명시적으로 특정 ID를 사용하지 않고, 시간/공간/기타 조건을 이용한 조회도 가능하다.

- 정보 수집을 통하여 얻어진 정보들을 분석한 결과, 시설물 제어가 필요할 경우 [4.3 제어 인터페이스]를 사용하여 시설물에 해당 조치를 취할 것을 스마트도시 통합운영센터에 요청한다.

- 시설물의 정보 수집이나 제어 도중 이상이 발생할 경우 스마트도시 통합운영센터는 실패 Ack를 반환한다. 이를 통해 문제가 발생한 시설물을 쉽게 추적할 수 있고, 이는 효율적인 자원 활용을 가능하게 한다.

- 시설물의 동작과 관련이 있는 시설물 주변의 정보에 대해 수집 및 관리가 가능해짐에 따라 시설물의 동작 방식을 개선할 수 있고, 시설물의 수명을 미리 예측할 수도 있다.

Ⅰ.2. 서비스 연계 시나리오 2 – 방범 방재 분야 서비스

가. 공공지역 감시 서비스

- 공공지역 감시 서비스는 보안이 필요한 공공지역에 대한 감시를 수행함으로써 인근 거주민과 공공지역의 안전을 확보하고자 하는 서비스이다.

- 보안이 필요한 공공지역에 대한 감시를 수행하기 위하여 해당 지역에는 CCTV와 같은 디바이스, 안전 감지를 위한 센서들이 설치되어 있다.

- 공공지역 감시 서비스는 [4.4 데이터 조회 인터페이스]를 활용하여 스마트도시 통합운영센터에 필요한 정보를 요청함으로써 정보를 수집한다.

- [4.3 제어 인터페이스]에 있는 controlDevice(DeviceId id, Command cmd) 인터페이스를 사용하여 스마트도시 통합운영센터에 특정 ID를 가지는 센서나 CCTV의 제어를 요청할 수 있다. 이 제어 인터페이스를 통해 Command를 전달 받은 스마트도시 통합운영센터는 해당 장치를 대상으로 명령을 수행하여 문제 없이 수행하였을 경우 공공지역 감시 서비스에게 성공 Ack를 반환한다. 이상이 발생하였을 경우에는 실패 Ack를 반환하여 문제가 발생하였음을 알린다.

- 4.4 데이터 조회 인터페이스]를 이용하여 스마트도시 통합운영센터에 지역에 대한 정보 조회를 요청할 수 있다. 이 때, 우범 지역을 공간 조건으로, 감시가 많이 요구되는 시간대를 시간 조건으로 설정해서 집중적인 감시가 필요한 지역 및 시간에 자원을 집중할 수 있다.

- subscribeDeviceData(DeviceId id, NotificationURI nURI) 인터페이스를 활용하여 지속적으로 정보 조회를 함으로써 돌발 상황을 대비한 모니터링을 수행한다.

- 돌발 상황 발생 시, [4.3 제어 인터페이스]를 통해 스마트도시 통합운영센터가 주변의 경보장치를 동작시키도록 하고, [4.5 데이터 전송 인터페이스]의 sendDeviceData (SpatialCondition scond, DeviceData ddata) 인터페이스를 활용하여 위급 상황을 알리는 정보를 인근 거주민들의 단말에 전송할 수 있도록 한다. 해당 장치가 명령을 문제없이 수행하였을 경우 공공지역 감시 서비스는 성공 Ack를 반환 받는다. 이상이 발생하였을 경우에는 실패 Ack를 받게 되고, 문제가 발생하였음을 알 수 있다.

나. 재난 재해 정보 서비스

- 재난 등 긴급한 상황이 발생했을 때 피해가 예상되는 주민들에게 위급한 상황임을 알리고 재난 관련 정보를 제공함으로써 거주민의 안전을 확보하고자 하는 서비스이다.

- [4.4 데이터 조회 인터페이스]에 있는subscribeDeviceData(DeviceId id, NotificationURI nURI) 인터페이스를 활용하여 지속적인 정보 조회를 요청하여 정보를 제공 받음으로써 재난 상황에서의 모니터링을 수행한다.

- 데이터 조회 인터페이스 이용 시 재난 발생 가능성이 높은 지역을 공간 조건으로 (예로, 지진 위험 지역), 감시가 많이 요구되는 시기를 시간 조건으로 설정 (예로, 장마철의 홍수 패해 대비) 해서 집중적인 감시가 필요한 지역 및 시간에 자원을 집중할 수 있다.

- 돌발 상황 발생 시, [4.3 제어 인터페이스]를 통해 스마트도시 통합운영센터가 주변의 경보장치를 동작시킬 수 있도록 하고, [4.5 데이터 전송 인터페이스]의 sendDeviceData (SpatialCondition scond, DeviceData ddata) 인터페이스를 통하여 위급 상황을 알리는 정보를 재난 발생 지역 인근 거주민들의 단말에 전송시킨다. 전송이 문제 없이 수행되었을 경우 성공 Ack를 반환하고, 이상이 발생하였을 경우에는 실패 Ack를 반환하여, 재난 재해 정보 담당 단위 서비스가 문제 발생 여부를 알 수 있게 한다.

- 재난 발생시 거주민들은 재난 재해 정보 서비스가 데이터 조회 인터페이스를 통하여 재난 재해와 관련된 정보 조회를 요청함으로써 필요한 정보를 열람할 수 있다.

Ⅰ.3. 서비스 연계 시나리오 3 – 스마트도시전기안전 서비스

- 전기누전, 과전류, 전기불꽃 징후 감지 등 전기안전에 이상이 감지되거나 발생했을 때 해당 시설의 전기설비(수전반, 배전반, 분전반)의 정보를 분석하여 예방점검을 실시하거나 제어명령 전달로 전기불꽃 사전차단, 과부하 방지, 과전류 차단, 전기사용량 및 트랜드 분석을 통하여 전기화재로 인한 사고를 사전 차단한다.

- [4.4 데이터 조회 인터페이스]에 있는subscribeDeviceData(DeviceId id, NotificationURI nURI) 인터페이스를 활용하여 지속적인 정보 조회를 요청하여 정보를 제공 받음으로써 전기 설비에 대한 상태감시를 수행한다.

- 데이터 조회 인터페이스 이용 시 전기 이상 징후가 포착되는 전기설비 현장담당자의 휴대용 단말기로 [4.5 데이터 전송 인터페이스]에 있는 sendDeviceData(DeviceID id, Devicedata Ddata) 인터페이스를 활용하여 현장점검을 요청한다.

- [4.3 제어 인터페이스]를 통해 해당 전기설비에 대한 전기사용량 제한 등에 대한 설정 값을 전송하여 전기사용에 대한 제한을 한다.

[그림 Ⅰ-2] 그림제목 쓰기

표준작성 공헌자

표준 번호 : SSF-CS-01

이 표준의 제․개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분	성명	위원회 및 직위	연락처 (E-mail 등)	소속
표준제안	최지원	사무국		스마트도시협회
	여화진	사무국		스마트도시협회
	진가연	사무국		스마트도시협회
표준초안제출
	최지원	사무국		스마트도시협회
	여화진	사무국		스마트도시협회
	진가연	사무국		스마트도시협회
표준(안) 작성 및 자문	최남희	자문위원장		한국교통대학교
	김민영	자문위원회 위원		오픈잇
	김영준	자문위원회 위원		LH
	김영혁	자문위원회 위원		오산시
	김용운	자문위원회 위원		한국전자통신연구원
	김은주	자문위원회 위원		한국정보화진흥원
	서재두	자문위원회 위원		정보통신산업진흥원
	송지성	자문위원회 위원		LGCNS
	윤정호	자문위원회 위원		안양시
	이강해	자문위원회 위원		한국정보통신기술협회
	이상훈	자문위원회 위원		LH 토지주택연구원
	이재용	자문위원회 위원		국토연구원
	이재한	자문위원회 위원		SKT
	이창호	자문위원회 위원		ESE
	송계수	-		국토교통과학기술진흥원
	유승덕	TFT장		문엔지니어링
	권준철	TFT 위원		썬즈
	김경호	TFT 위원		㈜지오멕스소프트
	김동준	TFT 위원		티맥스소프트
	김학철	TFT 위원		대신네트웍스

구분	성명	위원회 및 직위	연락처 (E-mail 등)	소속
표준(안) 작성 및 자문	류동주	TFT 위원		비트레스(주)
	백두현	TFT 위원		㈜위니텍
	윤팔희	TFT 위원		지오투정보기술
	이범서	TFT 위원		하이브시스템
	전창호	TFT 위원		㈜쿠도
	진희철	TFT 위원		㈜새눈
	최규태	TFT 위원		비에스테크
	최상도	TFT 위원		모코엠시스
	한재호	TFT 위원		엔텔스
	홍정호	TFT 위원		루키스
표준안 심의	김은형	표준위원장		가천대학교
	권준철	표준위원		썬즈
	김영준	표준위원		LH
	김정욱	표준위원		상명대학교
	나준엽	표준위원		한국건설기술연구원
	류동주	표준위원		비트레스
	박성수	표준위원		KT
	박찬호	표준위원		정도UIT
	송지성	표준위원		LG CNS
	이광근	표준위원		한국스마트홈산업협회
	이상훈	표준위원		토지주택연구원
	이준섭	표준위원		ETRI
	정용규	표준위원		을지대학교
사무국 담당	최지원	사무국		스마트도시협회
	여화진	사무국		스마트도시협회
	진가연	사무국		스마트도시협회

※ 국영문 표준제목 표기

스마트도시표준화포럼 표준

스마트도시 통합운영센터 플랫폼 서비스 인터페이스 모델

(The Service Interface Model for the Integrated Platform of Smart City Operation Center)

발행인 : 조근환

발행처 : 스마트도시표준화포럼

08506 서울특별시 금천구 가산디지털2로 98 롯데IT 캐슬

Tel : 02-3667-5005, Fax : 02-2051-8815

발행일 : 20XX.X.XX

본 문서에 대한 저작권은 스마트도시표준화포럼에 있으며, 이 문서의 전체 또는 일부에 대하여 상업적 이익을 목적으로 하는 무단 복제 및 배포를 금합니다.

Copyrightⓒ Korea Smart City Standardization. All Rights Reserved.